Add CoreVideo Tiles and harden live media - #401

…esign

The bar is now stated: plugin parity is the FLOOR, not the target. An operator
running a show on the plugin must not find a workflow missing in Pro, and where
Pro's architecture allows a better implementation it takes it.

The charter carries a verified feature inventory - derived by reading Pro's
source against the plugin's documented surface at v0.1.39, with the evidence for
every gap so each one can be re-checked. Three are worth naming here because
they were invisible until someone looked: the Tiles styling that #401 persists
is never drawn (grep glow across native/src returns nothing), the Spotlight
route mode cannot resolve because the SDK callback is a no-op stub in all three
engines, and the director has no manual take/release at all.

The Tiles design puts the wall in the core. This is forced, not chosen: animated
reflow needs a 60Hz clock, and the only way to drive that from the shell is a
frame-rate command path - the exact churn class that fail-fasts WinUI. The shell
keeps membership policy and styling; the core owns the solve, the clock, and the
draw. Per-tile overrides keep the canvas editor working, which also makes a
pinned host tile beside a reflowing gallery an ordinary code path rather than a
special case - a layout the plugin cannot express.

Two decisions are recorded against their alternatives so nobody re-litigates
them cheaply: a configure-tiles command was rejected because one-shot commands
are silently lost on core respawn (that already shipped once as the multiviewer
being broken), and the shell stops solving layout entirely rather than keeping a
second solver that would drift from the core's.

The wall is judged on PIXELS. This repo has been burned twice by validators that
checked a proxy which survived the bug.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Second crash from the same live meeting, and the third instance of one family.
Selecting a Tiles scene on the Sources tab overflowed the stack: dump
CoreVideoPro.WinUI.exe.38368.dmp is c00000fd with a RECURRING_STACK across
Update_ViewModel_GalleryTileAspect, Selector.set_SelectedValue and back into the
setter.

The cycle: any Gallery* setter calls UpdateGallery, which raises PropertyChanged
for EVERY gallery property; XAML pushes the value into the ComboBox's
SelectedValue; that binding is Mode=TwoWay, so it writes the value straight back
into the setter, which calls UpdateGallery again. WinUI does not short-circuit
the echo, so nothing terminates it - it recurses until the guard page cannot be
created.

Pre-existing on main: git diff against the merge-base shows this branch touches
none of GalleryTileAspect, UpdateGallery, NotifyDynamicGalleryPropertiesChanged
or GalleryBorderShape. Like the null-scene-id crash an hour earlier, it is the
#401 Tiles UI, which appears never to have been clicked in a running app.

The guard drops the re-entrant write, which is correct - it is the binding
echoing a value the model already holds. The real fix remains the one CLAUDE.md
already prescribes for this family: do not drive Selector.SelectedValue from a
TwoWay x:Bind.

Found by running a live meeting against the branch before merging. Two crashes,
two pre-existing bugs, neither reachable by any test we have.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>